This invention relates to digital processors, and more particularly to development tools for such processors.
Microprocessors have found their way into a huge variety of products. Often the processor and its programming is completely xe2x80x9cembeddedxe2x80x9d into the design of the device, hence the term xe2x80x9cembedded processorsxe2x80x9d to describe such processors. Several examples of devices having embedded processors are cellular telephones, computer printers, high performance disk drives for computer data, and automobile control systems.
Development tools that are useful for general purpose (non-embedded) processors are not satisfactory for embedded processor development. In other words, the test procedures for production of the processor itself may not be satisfactory for testing the processor in its embedded environment. It is more difficult to have visibility into processor operation. To solve this problem, one technique that is being increasingly used is referred to as xe2x80x9cemulationxe2x80x9d.
In general, an emulator, whether software or hardware, permits direct control by a designer over a target processor. Because it is the application in which the processor will be used, and not the processor itself, that is being designed, the emulator must emulate the processor""s operation.
In-circuit emulation, commonly referred to as ICE, uses emulators that are typically a combination of hardware and software. The emulator is typically connected between the embedded processor and a host CPU that is running debugging software. The emulation is xe2x80x9cin-circuitxe2x80x9d in the sense that the processor may be connected to the emulator while it is embedded into the system in which it is to be embedded.
Real-time in-circuit emulation permits a software designer to monitor, analyze, and modify code without impacting operation of the device in which the processor is embedded. The behavior of the emulator is identical to that of the target processor. For example, in the case of an embedded processor for a disk drive, the emulator might permit the designer to modify the code while the disk drive continues to run normally.
One aspect of the invention is a reconfigurable datapath that can provide multiple debug functions. The datapath is comprised of the following elements: a first set of register bitcells that form a reference register bitcell unit, a second set of register bitcells that form a mask register bitcell unit, and a set of comparator bitcells that form a comparator bitcell unit. Each of the register bitcells has a half adder, a register input multiplexer for selecting between a number of inputs, at least one said input being a counter input from the half adder and at least one input being a write input, and a flip flop for storing a selected one of the inputs. The half adder receives a carry chain input and the output of the flip-flop. Each of the comparator bitcells has NOR logic for receiving a bus input and a mask input, as well as XOR logic that receives the output of the NOR gate and a signal from the reference register unit. The XOR logic provides a compare result signal that is used differently (or not used) depending on the debug mode for which the datapath is configured. The interconnections between the bitcell units and their inputs determine whether the datapath is to be used in a breakpoint mode, counter mode, DMA (direct memory access) mode, or PSA (parallel signature analysis) mode.
An advantage of the invention is that debug functions are implemented with a single reconfigurable datapath, rather than with a different module for each function. The cost of the debug logic is reduced. The different modes can be configured on the fly, by changing the contents of a configuration register. The reconfigurable datapath may be used in conjunction with a software debug system or as part of a xe2x80x9cself-debugxe2x80x9d unit of a processor.